In the last decade, the number of computers connected to the Internet has increased by an enormous order of magnitude. High growth in the number of Internet connections has put severe pressure on the available address-space of routable internet protocol (IP) addresses. To overcome the problem of limited and diminishing IP address-space, it became imperative to have a solution that would allow multiple users to share a single routable internet address. The commonly used solution for sharing a single IP address is known as a Network Address Translator (NAT). Operation of a typical NAT is described next.
The basic concept underlying a NAT is to have a device or software module that allows sharing of one or more routable Internet Protocol (IP) addresses by multiple computers. A typical NAT is connected to the public internet on one side and has at least one global or public IP address for receiving and sending data packets from and to the public internet. On the other side of the typical NAT is a private network, in which each network node (computer) is assigned a local arbitrary addresses. Typically, the NAT assigns arbitrary addresses to the nodes of the private network using a Dynamic host Control Protocol (DHCP) or alternatively the NAT assigns static translation addresses.
According to Simple Traversal of UDP through NAT (“STUN”, where UDP is the acronym for User Datagram Protocol), there are five basic types of NAT in the Background Art. It is helpful to discuss the differences between the types of NAT, which will be done in terms of the simplistic system block diagrams of Background Art FIGS. 4A-4E.
FIG. 4A depicts a system 400 according to the Background Art that includes: an endpoint device 404; an endpoint device 406 having an IP address X and ports p and q; an endpoint device 408 having an IP address Y and ports p and q; and a full cone type of NAT 404. Devices 404, 406 and 408 are described as “endpoint” devices because they can be the endpoints of a communication session, e.g., between device 404 and device 406 or between device 404 and device 408. While there will be at least one intermediary device, namely the NAT 402, between the endpoint devices, the endpoints themselves are not intermediary devices for the purposes of this explanation.
The endpoint devices 404, 406 and 408, respectively, can be, e.g., a host of server such as an HTTP server, a host of browser such as an HTTP browser, an IP video camera, etc. Typically, the endpoint device 404 is part of a first network 418, and the endpoint devices 406 and 408 are part of a second network 419. The full-cone NAT 402 can be considered as part of each of the first network 418 and the second network 419. The endpoint devices 406 and 408 communicate with the endpoint device 404 via the full-cone NAT 402, and vice-versa, respectively.
In general, any type of the four types of NAT will allocate oh map an address and port-number pair to the endpoint device 404. As a practical matter, this address/port pair makes it seem to devices on the second network 419 as if the endpoint device 404 is directly connected to the second network 419. In particular, the full-cone NAT 402 will accept a packet from any device on the second network 419, e.g., endpoint devices 406 or 408.
In FIG. 4A, a packet (not depicted) can be sent from the endpoint device 404 to the endpoint device 406 through the full-cone NAT 402 using the destination address/port pair X,p, as indicated by path 410. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p will be accepted by the full-cone NAT 402 (and passed along to the endpoint device 404), as indicated by the path 412.
The nature of the full-cone NAT 402 is to accept a packet whose destination address/port pair is the address/port pair mapped to the endpoint device 404, regardless of the packet's source address, i.e., regardless of whether the source address and/or source port of the received packet matches a destination address of a packet previously sent from the endpoint device 404 via the full-cone NAT 402 to the second network 419. As such, packets (not shown) having the following source address/port pairs will also be accepted by the full-cone NAT 402: X,q as indicated by path 413; Y,p as indicated by path 414; and Y,q as indicated by path 416.
In contrast, other types of NAT depicted in FIGS. 4B, 4C, 4D and 4E each exhibit greater restrictions upon what types of packets coming from the second network 419 will be accepted.
FIG. 4B depicts a system 420 that is similar to the system 400 except that an address-restricted cone type of NAT 422 is present instead of the full-cone NAT 402.
In FIG. 4B, a packet (not depicted) can be sent from the endpoint device 404 to the endpoint device 406 through the address-restricted NAT 422 using the destination address/port pair X,p, as indicated by path 424. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p will be accepted by the address-restricted NAT 422 (and passed along to the endpoint device 404), as indicated by the path 424.
The more-restricted nature of the address-restricted NAT 422 is to accept a packet whose destination address/port pair is the address/port pair mapped to the endpoint device 404 so long as the source address in the received packet matches a destination address of a packet previously sent from the endpoint device 404 via the address-restricted NAT 422 to the second network 419, regardless of whether the source port matches the destination port of the packet previously sent from the endpoint device 404 via the full-cone NAT 422 to the second network 419. As such, a packet (not shown) having the address/port pair X,q will be also be accepted by the full-cone NAT 422, as indicated by path 426.
But packets having the following source address/port pairs will not be accepted (i.e., will be blocked) by the full-cone NAT 402: Y,p as indicated by path 430; and Y,q as indicated by path 432. Again, this is because the source addresses of the packets of path 430 and 432 do not match a destination address of a packet previously sent by the address-restricted NAT 422, e.g., such as the destination address of the packet of path 424.
FIG. 4C depicts a system 440 that is similar to the system 420 except that an address&port-restricted (“port-restricted”) cone type of NAT 442 is present instead of the address-restricted NAT 422.
In FIG. 4C, a packet (not depicted) can be sent from the endpoint device 404 to the endpoint device 406 through the port-restricted NAT 442 using the destination address/port pair X,p, as indicated by path 444. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p will be accepted by the port-restricted NAT 442 (and passed along to the endpoint device 404), as indicated by the path 446.
The further-restricted nature of the port-restricted NAT 442 is to accept a packet whose destination address/port pair is the address/port pair mapped to the endpoint device 404 so long as the source port as well as the source address in the received packet matches a destination address/port pair of a packet previously sent from the endpoint device 404 via the port-restricted NAT 442 to the second network 419. Consequently, packets having the following source address/port pairs will not be accepted (i.e., will be blocked) by the port-restricted NAT 442: X,q as indicated by path 448; Y,p as indicated by path 450; and Y,q as indicated by path 452.
Again, though the packet of path 448 has a source address that matches the destination address for the packet of path 444, the source port does not match a destination port of a packet previously sent via the port-restricted NAT 442. And both of the source addresses and source ports of the packets of paths 450 and 452, and hence their respective address/port pairs, fail to match the address/port of a packet previously sent via the port-restricted NAT 442.
FIG. 4D depicts a system 460 that is similar to the system 440 except that a symmetric and port-sensitive (“SYMS”) type of NAT 462 is present instead of the port-restricted NAT 442. For the purposes of this explanation, it is assumed that the SYMS 462 has mapped two address/port pairs to the endpoint device 404; namely: a first address/port pair having the address of the SYMS 462 and port:v; and a second pair having the same address but using port:w.
In FIG. 4D, a packet (not depicted) can be sent from the endpoint device 404 to the endpoint device 406 through port-v of the SYMS 462 using the destination address/port pair X,p, as indicated by path 464. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p and the destination port-v will be accepted by the SYMS 462 (and revised and then passed along to the endpoint device 404), as indicated by the path 466.
The yet further-restricted nature of the SYMS 462 is similar to the port-restricted NAT 442, albeit with a significant difference. For each different destination address/port pair that the endpoint device 404 sends a packet, the SYMS 462 allocates/maps a separate address/port pair. For a packet to be accepted from the second network 419 by the SYMS 442, the packet's combination of destination port and source address/port pair should match the combination of source port and destination address/port pair, respectively, of a packet sent to the second network 419 via the SYMS NAT 462.
It is assumed for the purposes of explanation that a packet will be sent from the endpoint device 404 to each of the endpoint devices 406 (specifically at port:p) and 408 (specifically at port:q) via the SYMS 462.
For use with respect to port:p of the endpoint device 406 (address/port pair X,p), the SYMS 462 maps its port:v to the endpoint device 404. Similarly, for use with respect to port:q of the endpoint device 408 (address/port pair Y,q), the SYMS 462 maps its port:w to the endpoint device 404. The packet (not depicted) sent to port:p of the endpoint device 406 through port:v of the SYMS 462 is indicated by path 464, while the packet (not depicted) sent to port:q of the endpoint device 408 through port:w of the SYMS 462 is indicated by path 470. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p will be accepted by the SYMS 462 (and revised and then passed along to the endpoint device 404), as indicated by the path 466. Similarly, a packet (not depicted) sent by the endpoint device 408 using the source address/port pair Y,q will be accepted by the SYMS 462, as indicated by the path 472.
But packets having the following source address/port pairs will not be accepted (i.e., will be blocked) by the SYMS 462: X,q as indicated by path 468; and Y,q as indicated by path 474. Again, though the address portion of the source address/port pair of the packet of path 468 matches an address portion of a packet previously sent via the SYMS 462, the port portion (namely port:q) of the source address/port pair does not match.
FIG. 4E depicts a system 480 that is similar to the system 460 except that a symmetric and port-insensitive (“SYMI”) type of NAT 482 is present instead of the port-restricted NAT 462. For the purposes of this explanation, it is assumed that the SYMI 482 has mapped two address/port pairs to the endpoint device 404; namely: a first address/port pair having the address of the SYMI 462 and port:v; and a second pair having the same address but using port:w.
In FIG. 4E, a packet (not depicted) can be sent from the endpoint device 404 to the endpoint device 406 through port-v of the SYMI 462 using the destination address/port pair X,p, as indicated by path 484. Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p and the destination port-v will be accepted by the SYMI 462 (and revised and then passed along to the endpoint device 404), as indicated by the path 486.
The further-restricted nature of the SYMI 482 is similar to the port-restricted NAT 462, albeit with a significant difference that makes the SYMI 482 somewhat similar also to the address-restricted NAT 422. For each different destination address (not address/port pair as with the SYMS NAT 462) that the endpoint device 404 sends a packet, the SYMI 462 allocates/maps a separate address/port pair. The SYMI type of NAT 462 can have two implementations: loose (not separately depicted); and tight (not separately depicted). Depending upon the particular implementation, one of two initialization scenarios, namely tightly initialized or loosely initialized, will describe what sort of initialization should take place before a packet from the second network 419 will be accepted by the SYMI NAT 482.
First, the loosely initialized scenario for a loose SYMI NAT 482 will be described. For a packet to be accepted from the second network 419 by the loose SYMI NAT 482, the packet's combination of destination port and source address (but not also source port) should match the combination of source port and destination address, respectively, of a packet sent to the second network 419 via the loose SYMI NAT 482. In terms of an example, despite the loose SYMI NAT 482 having not sent a packet to port:q of the endpoint device 406 (again, address X) via port:v (of the NAT 482), a packet having source address/port pair X,q (i.e., coming from port:q of the endpoint device 406) nevertheless will be accepted by the loose SYMI NAT 482 (e.g., at its port:v) if the SYMI NAT 482 has been loosely initialized. Being loosely initialized should be understood as meaning that a packet previously has been sent (in the context of this example) to the endpoint device 406 at another port, e.g., port:p (destination address/port pair X,p) via the SYMI NAT 482.
The tightly initialized scenario for a tight SYMI NAT 482 will now be described. For a packet to be accepted from the second network 419 by the tight SYMI NAT 482, the packet's combination of destination port and source address/port pair (i.e. the combination of source port and source address) should match the combination of source port and destination address/port pair, respectively, of a packet sent to the second network 419 via the tight SYMI NAT 482. In terms of an example, a packet having source address/port pair X,q (i.e., coming from port:q of the endpoint device 406) will be accepted by the tight SYMI NAT 482 (e.g., at its port:v) if the SYMI NAT 482 has been tightly initialized. Being tightly initialized should be understood as meaning that a packet previously has been sent (in the context of this example) to the endpoint device 406 at the same port, e.g., port:q (destination address/port pair X,q) via the SYMI NAT 482.
After initialization, the loose and tight implementations of the SYMI NAT 482 behave the same. For a packet to be accepted from the second network 419 by the SYMI NAT 482 after initialization, the packet's combination of destination port and source address (but not also source port as with the SIMS NAT 462) should match the combination of source port and destination address, respectively, of a packet sent to the second network 419 via the SYMI NAT 482. In other words, similar to the address-sensitive NAT 422, for each port on the SYMI NAT 482, the SYMI NAT 482 (again, after initialization) will accept packets from different source ports so long as their source address is the same as a packet previously sent to the second network 419 via the SYMI NAT 482.
It is assumed for the purposes of explanation that a packet will be sent from the endpoint device 404 to each of the endpoint devices 406 (specifically at port:p) and 408 (specifically at port:q) via the SYMI NAT 482.
For use with respect to the endpoint device 406 (address X), the SYMI NAT 482 maps its port:v to the endpoint device 404. Similarly, for use with respect to the endpoint device 408 (address Y), the SYMI NAT 482 maps its port:w to the endpoint device 404. The packet (not depicted) sent to port:p of the endpoint device 406 through port:v of the SYMI NAT 482 is indicated by path 484, while the packet (not depicted) sent to port:q of the endpoint device 408 through port:w of the SYMI NAT 482 is indicated by path 490.
Not surprisingly, a packet (not depicted) sent by the endpoint device 406 to the endpoint device 404 using the source address/port pair X,p will be accepted by the SYMI NAT 482 (and revised and then passed along to the endpoint device 404), as indicated by the path 486. Similarly, a packet (not depicted) sent by the endpoint device 408 using the source address/port pair Y,q will be accepted by the SYMI NAT 482 (again, after initialization), as indicated by the path 492. Moreover, packets having the following source address/port pairs will also be accepted (i.e., will not be blocked) by the SYMI NAT 482 (again, after initialization): X,q as indicated by path 488; and Y,q as indicated by path 494.
The full cone NAT 402, the address-restricted NAT 422 and the port-restricted NAT 442 each permits a ratio of 1:N (where N can be any positive integer) between one of its own ports and source addresses or source address/port pairs, respectively, on the second network 419. The 1:N ratio is what gives rise to each of the NATs 402, 422 and 442 being described with the term “cone.”
In contrast, each of the SYMI NAT 482 and the SIMS NAT 462 permits only a ratio of 1:1 between one of its own ports and a source address or a source address/port pair, respectively, on the second network 419. The 1:1 ratio is what gives rise to each of the NATs 482 and 462 being described with the term “symmetric.”
An analogy will be provided to aid the explanation of how the various NATs operate.
The analogy is couched in terms of a doorman to a building (corresponding to the first network 418) in which endpoint device 404 is located. Each of the NATs 402, 422, 442 and 462 can act as a wall of the building. Until the NAT allocates/maps an address/port pair to the endpoint device 404, there are no doors in any of the walls of the building by which a packet from the second network 419 could gain entry or a packet from the endpoint device 404 could leave.
When the NAT allocates/maps an address/port pair to the endpoint device 404, the effect is as if the NAT creates a door in the wall that it represents. From the perspective of the second network 419, the NAT will act as a doorman relative to the doors that it has created.
The NAT (as doorman) keeps the door it created (for the endpoint device 404) closed until the endpoint device 404 sends a packet to the second network 419 via the NAT. In other words, the NAT (as doorman) will not let through packets (from the second network 419) appearing at the door (i.e., where the packet has a destination address the address/port pair allocated/mapped to the endpoint device 404) until the NAT opens the door.
When the endpoint device 404 finally does send a packet to the second network 419 via the NAT, initially the packet's indicated source address is the address on the first network 418 of the endpoint device 404. The NAT revises it so that the packet's indicated source address information becomes the address/port pair which the NAT has allocated to the endpoint device 404, and then passes along the revised packet to the second network 419. In revising and passing along the packet, the effect is as if the NAT (as doorman) opens the door that it has created so that certain packets (depending upon the type of NAT) coming from the second network can pass through the doorway.
The full-cone NAT 402, in its role as doorman, will let through the door any packet appearing at the door (i.e., received by the NAT 402) that is intended for the endpoint device 404 (i.e., whose destination address is the address/port pair that the NAT 402 has mapped to the endpoint device 404). The NAT 402 (as doorman) is the least discriminating type of NAT about what packets it lets through its opened doors. The other NATs 422, 442 and 462 are increasingly more discriminating in their roles as doorman, respectively, checking more than just the packet's destination address/port pair.
The other NATs 422, 442, 462 and 482 treat the packets sent out from the endpoint device 404 as invitations corresponding to a guest list. In their roles as doormen, NATs 422, 442, 462 and 482 act as though they check whether packets appearing at their doors are on a guest list. As should be expected, the guest lists of the NATs 422, 442, 462 and 482 are more selective, respectively, than the full-cone NAT 402.
To be on the guest list for a door opened by the address-restricted NAT 422, a packet from the second network 419 should also have a source address (but not necessarily a source port) that matches a destination address of an invitation (packet) previously sent by the endpoint device via the NAT 422. To be on the guest list for a door opened by the port-restricted NAT 442, a packet from the second network 419 should also have a source address/source port pair that matches a destination address/port pair of a previously sent invitation packet.
Like the port-restricted NAT 442, being on a guest list maintained by the SYMS 462 in its role as doorman requires that a packet from the second network 419 should also have a source address/source port pair that matches a destination address/port pair of an invitation (packet) previously sent by the endpoint device via the NAT 422. The port-restricted NAT 442 opens only one door for the endpoint device 404 (through which packets of varying destination address can be sent). As such, the port-restricted NAT 442 maintains only one guest list for the endpoint device 404.
In contrast, the SYMS 462 creates/opens a door for each destination address to which the endpoint device 404 sends a packet. Accordingly, the SYMS 462 (as doorman) maintains a separate guest list for each door it creates/opens for the endpoint device 404. So in FIG. 4D, a packet having destination port:v and source address/port pair Y,q would not be on either the guest list corresponding to door:v (port:v) or door:w (port:w). This is because the endpoint device 404 never sent a packet to source address/port pair Y,q via port:v. Rather, the packet sent to source address/port pair Y,q was sent via port:w (again, see path 470).
Like the SYMS NAT 462, the SYMI NAT 462 (as doorman) maintains a separate guest list for each door it creates/opens for the endpoint device 404. But unlike the SYMS NAT 462, the SYMI NAT 462 (as doorman) creates/opens only one door for each address on the second network 419, i.e., different ports of the same address use the same door created/opened by the SYMI NAT 462 albeit after initialization.
So in FIG. 4E, after initialization, the packet (not depicted) of path 488 having destination port:v and source address/port pair Y,q is on the guest list corresponding to door:v (port:v). Similarly after initialization, the packet (not depicted) of path 494 having destination port:w and source address/port pair Y,p is on the guest list corresponding to door:w (port:w).
This concludes explanation of the analogy.
The NAT provides a convenient way of providing shared and transparent communication between the public internet and the computers (attached to a private network) having a non-globally-unique IP address, i.e., an IP address that is not globally-unique. However, not all forms of communications are operable over a NAT. This is a problem. Many types of applications require a globally-unique IP address as a termination point or require IP address consistency over the whole communication cycle. For example, an IP enabled phone will typically require a globally-unique IP address to receive and send voice-transmission using the IP. The presence of a NAT at the receiving end of the IP phone call may block the receiver (the endpoint device) from receiving the phone IP packets.
The presence of NATs in a network poses another type of problem as described next. There is no simple and convenient way to access a server type of device located behind a NAT from the public internet side of the NAT. For example, if a Hypertext Transfer Protocol (HTTP) webserver is located behind a NAT, then it has a private address which is invisible to the outside world through the public internet. On the contrary, a typical webserver, e.g., an HTTP server, which is not behind a NAT is readily accessible from the public internet if it has an IP address that can be resolved using common methods like the Domain Name System (DNS).
TCP/IP allows multiple applications to run on a single computer using a variety of port numbers. When a NAT is used by a private network to share an IP address, then the port addresses are shielded behind the NAT from the outside network. This situation can be further complicated by presence of a firewall with a security policy that does not allow access to specific ports of the computers on the private network as described next.
A port-forwarding solution creates a “tunnel” through the firewall so that external users from the public internet can access a specific computer in the private network using the designated port for the tunnel. Typically, a port forwarding solution has a maximum number of about five forwarded port entries. But many applications like network-gaming, instant messaging and collaboration software may require access to previously “unopened” specific TCP/UDP ports from the external public internet. Creating all the required tunnels for such applications can be an impractical task for a typical user, since the tunnel configuration process can be complicated and confusing. Port forwarding is typically a kind of functionality provided by a router, hence it typically raises a need for a specific router that has an inbuilt port forwarding capability.
The presence of a NAT may not affect the network much if the transport connections are initiated from the clients that are behind the NAT. But if a server is located behind a NAT, then IP requests originating from the public network may not be able to access the server due to the presence of the NAT. An approach to solve this problem, and its drawbacks are discussed next. In a Dynamic Domain Name System (DDNS) the users attempting to access a server located behind a NAT using a Fully Qualified Domain Name (FQDN) may face problems. Such problems result from the situation when a server or device behind a NAT is assigned a private IP address by a NAT which is invisible. A DDNS trying to route packets to an IP address due to a FQDN access request will fail since the NAT-assigned private address is invisible to the public internet side of the NAT.
Attempts have been made to define protocols for solving the NAT traversal problem described above. For example, protocols such as TURN (Traversal Using Relay NAT), STUN (Simple Traversal of UDP through NAT), SPAN-A (Simple Protocol for Augmenting NATS), etc., provide an approach that does not require routers to have the specific functionality of supporting NAT traversal. However, these protocols do not provide a complete NAT traversal mechanism. These protocols are to be handled by an application known as SIP (Session Initiation Protocol).
Gnutella is a Peer-To-Peer (P2P) file-sharing system. The Gnutella protocol (“The Gnutella Protocol Specification v0.4 Document Revision 1.2”) is widely used by Gnutella clone systems such as Kazaa, BearShare, etc. Unlike a centralized server network, the Gnutella protocol does not rely on a central server to keep track of all shared files. The Gnutella protocol uses multiple nodes known as “servents” each of which can become both a server and a client. The Gnutella protocol uses TCP protocol for a communication between the servents.
Once a servent finds an IP address of another servent which has a file the servent wants to download, it starts downloading the file through the TCP connection between the two. The Gnutella protocol can accommodate the presence of one NAT between two servents. If a servent is behind a NAT, other servents cannot initiate a TCP connection. In this case, the other servents send a “Push” descriptor to tell the server behind the NAT to initiate the TCP connection back to the other servents.